Conversation
This change follows with the work I did in upstream wasmtime to support guest profiling for components: bytecodealliance/wasmtime#10507 Integration tests for both components and core modules were added to ensure we have some coverage of the guest profiling (just ensuring it generates profiler output).
aeadcc9 to
5600294
Compare
| pub fn with_guest_profiling(mut self, config: viceroy_lib::GuestProfileConfig) -> Self { | ||
| self.guest_profile_config = Some(config); | ||
| self | ||
| } |
There was a problem hiding this comment.
Should there also be a with_profiling_strategy method for setting the profiling_strategy field?
There was a problem hiding this comment.
Yeah, I had plumbed that through but didn't write additional tests for those bits (as my changes are isolated to guest profiling). The naming and plumbing of some of these config bits is a bit confusing as the profiling strategy is unique to native profiling (not guest).
I have some changes now that consolidate things down to a single profiling_config which consolidates the guest/native/none paths in a single field. It's a fairly large change in terms of files touched, so I'm inclined to land this change as-is and then separately open up that change for review separately as it is beyond the scope of what we're changing here.
dgohman-fastly
left a comment
There was a problem hiding this comment.
Makes sense; thanks!
This change follows with the work I did in upstream wasmtime to support guest profiling for components: bytecodealliance/wasmtime#10507 Integration tests for both components and core modules were added to ensure we have some coverage of the guest profiling (just ensuring it generates profiler output).
This change follows with the work I did in upstream wasmtime to support guest profiling for components:
bytecodealliance/wasmtime#10507
Integration tests for both components and core modules were added to ensure we have some coverage of the guest profiling (just ensuring it generates profiler output).